The self-service site enables organizations to:

• Empower users to perform simple authentication management functions, such as resetting PINs and viewing authentication history, which helps to reduce the workload and user reliance on the help desk.

  To report a lost token, users must contact their administrator or help desk.

• Invite users to request a token. This is particularly useful for organizations servicing consumers of online subscription services. Users can now request a token as part of their subscription for other services.

• Create a customized yet automated workflow for approving token requests, and for fulfilling and shipping tokens to users.

• Offer a complete user-centric service, including multi-language support, customized prompts, messages, help, and navigation, all optimized for the user based on how they are interacting with self-service (browser type, screen resolution etc.).

Self-service functionality is exposed by the SafeNet Trusted Access platform as a web service (WSDL), giving developers the necessary tools to build some or all of the self-service functionality into a corporate portal. For more information about the self-service WSDL, contact Thales Group or your local vendor.

Extend self-service functionality

Typically, authentication self-service has been limited to extending some token management functionality to users, specifically PIN management, OTP resend, and token resync. The focus is almost always token-centric, assuming that all users are the same, have tokens, and that the only issues self-service need resolve are token-related.

In fact, many enterprises want to extend self-service functionality to people who:

• May or may not have tokens. In many organizations, the idea that users should be able to request a token (or services) makes sense, perhaps as part of some other service to which the user is subscribing. This is the pull concept.

• May or may not be known to the organization. Commonly, users belong to an organization. But this is not always the case. At a simple level, external parties, such as contractors or business partners, may require the service. The separation between the enterprise and the possible user community may broaden. Think of a user becoming a subscriber to your service for the first time. Until they sign up and are approved, the user is completely unknown. Therefore, self-service must accommodate communities that may become legitimate users of the service but are unknown to the service provider prior to “signing-up.”

• May have very diverse requirements, not the least of which is language. It’s difficult to contemplate providing a global self-service capability without considering the diversity of the community. It is very unlikely that users will all speak the same language or that hardware tokens shipped from Toronto will arrive in Montreal and Shanghai in the same time-frame. In other words, self-service needs to accommodate diversity in such a way as to maximize the simplicity of the user experience, regardless of language, logistics, and authentication method.

It is quickly apparent that the pull world demands a new set of tools by which administrators of authentication  services can extend self-service functions to current and potential users, determine the validity of requests, how each is to be handled and how, throughout the process, the user is kept informed.

The key elements to producing an effective and highly marketable self-service capability depend on:

• Ensuring that the approval process reflects the enterprise’s desired workflow

• Sufficient visibility at all stages of the workflow as to the status of a request

• Effective and simple workflow and communication with the user

What users do on the self-service site

Users must log in to the portal using one of the following options:

• Token: The user enters their User ID and an OTP that is generated by their assigned token.

• Password: The system sends the password by either email or SMS.

• Question and answer: Set when the user accesses the portal for the first time and then chooses to enter answers to the authentication questionnaire.

The self-service portal enables a user to perform simple authentication management functions, including:

• Reset their PIN and PIP

• Report lost tokens

• View their profile and authentication activity

• Test and resynchronize their tokens

• Resend SMS messages to their mobile device

The self-service capabilities reduce the workload and user-reliance on the Help Desk.

The self-service site can present users with the following services:

Service	Default icon
Request a Token: Used to create new user accounts and to service existing users. Enables a user to request a token from a list of approved token types and authentication methods. This service is not published by default.
Reset PIN: Allows a user to modify their server-side PIN without the assistance of the help desk. PIN changes must comply with the PIN policy. This service is published by default.
Reset PIP: This service allows users to modify the personal identification pattern (PIP) that is associated with their GrID authentication method, without the assistance of the help desk. The new PIP must comply with the PIP policy. This service is published by default.
Resync Token: Allows users to test and resync their token with the server without the assistance of the help desk. This service is published by default.
My Profile: This service can allow users to modify basic information about their account such as address, telephone number, and so on. It also presents basic statistics about their authentication activity, and allows them to manage challenge and response questions (if enabled). This service is not published by default.
Resend SMS: Allows a user to request an SMS or OTP to be resent to their registered mobile device.

Changing the default language on the self-service site

If a user wants to set their own personal language preference for the self-service site, they can do so on the self-service site login page and home page. At the bottom of the page, a text or icon link for languages is displayed, based on configuration of the self-service service (the default links are shown below).

To switch to another language, click the languages link and then select the language from the list. All text in the self-service site will be converted to the selected language upon login for that user only.

To change the default user language	Languages text link	Languages icon link
Select a link on the self-service site home page…
…and then select a language.

Configuring self-service

All self-service functionality, from what is presented to the user to back-office workflow, is configured through the Self-Service tab of the STA Token Management console.

Self-service is best viewed as three functional areas:

• The self-service website, through which users perform common functions.

• Presentation services, through which administrators customize the services, languages, and other aspects of self-service presented to users on the self-service site.

• Back-end workflow, through which administrators manage the services presented to users through the self-service website.

Self-service configuration and management is performed on the Self-Service tab:

• Configuring Self-Service module: Provides access to all of the functions related to customizing the site for appearance, user services, and back-office workflow, including approving and fulfilling user requests for tokens.

• Queue Management module: Provides lists of outstanding tasks related to user requests for tokens. Operators with appropriate authorities can view and process requests for tokens.

Self-service URLs

The base and unique URLs for the self-service site are automatically created when the virtual server account is activated. Do not modify these URLs unless you want to link to an alternative, stand-alone self-service site.

The Self-Service Unique URL must be provided to users. Clicking the link displays the self-service home page.